Hi @mdboom , could you please help review it?
Thanks!

IIUC, this happens when a git repository is queried by a different user than the one who owns the files in the git repo. Do we know why this is happening? Presumably the whole GHA workflow is run by the same user. Basically, I want to understand the root cause before approving (and also to understand if we should expect to see this issue with setuptools-scm in other workflows...)

@mdboom This problem was exposed because of the setuptools_scm upgrade. Previously, setuptools_scm 9.2.2 was used. Now it used setuptools_scm 10.0.5 when installing cuda_pathfinder.
The workspace directory was created by the runner user (which is not root) on the host and mounted into the Docker container. The pip install was executed by root inside the container. So root and the workspace directory owner were different, which caused git to reject the repository with "dubious ownership."

When running pip install -v . under cuda_pathfinder, it eventually calls _git_toplevel in vcs_versioning/_file_finders/_git.py.
In setuptools_scm version 10.0.5 (via vcs-versioning), this function raises SystemExit when detecting an ownership mismatch:
def _git_toplevel(path: str) -> str | None:
...
res = _run(["git", "rev-parse", "HEAD"], cwd=cwd)
if res.returncode:
if "--add safe.directory" in res.stderr and not os.environ.get(
"SETUPTOOLS_SCM_IGNORE_DUBIOUS_OWNER"
):
raise SystemExit(
"git introspection failed: {}".format(res.stderr.split("\n")[0])
)

In version 9.2.2, the same function simply logged the error and returned None, allowing the build to continue:
def _git_toplevel(path: str) -> str | None:
...
res = _run(["git", "rev-parse", "HEAD"], cwd=cwd)
if res.returncode:
log.error("listing git files failed - pretending there aren't any")
return None

One of the workaround is to mark the workspace as a safe directory after checkout: git config --global --add safe.directory "$GITHUB_WORKSPACE".

Thanks for the explanation, @rluo8. Can we try removing this line instead?

https://github.com/NVIDIA/cuda-python/blob/main/.github/workflows/coverage.yml#L49

That may fix the problem in a better way without ignoring a potentially important safety check. I experimented with removing it on our main CI, and it doesn't seem to be necessary, so maybe it will work for coverage as well.

Thanks @mdboom. I've removed the options: -u root --security-opt seccomp=unconfined --shm-size 16g line from the container config. Could you help trigger the coverage workflow to see if it works?

Thanks @mdboom. I've removed the options: -u root --security-opt seccomp=unconfined --shm-size 16g line from the container config. Could you help trigger the coverage workflow to see if it works?

Here's the coverage workflow: https://github.com/NVIDIA/cuda-python/actions/runs/23949027494

Thanks @mdboom. I've removed the options: -u root --security-opt seccomp=unconfined --shm-size 16g line from the container config. Could you help trigger the coverage workflow to see if it works?

Here's the coverage workflow: https://github.com/NVIDIA/cuda-python/actions/runs/23949027494

The coverage workflow failed. It seems that the docker container might use root as default user.
Could we change the owner of the workspace to the user who ran tests inside the container after checking out the workspace?
chown -R $(id -u):$(id -g) "$GITHUB_WORKSPACE"
After changing the owner, git command should pass as there is no dubious ownership.